home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 5 / Apprentice-Release5.iso / Source Code / C / Applications / Python 1.3.3 / Python 133 SRC / Mac / Relnotes-1.1 < prev    next >
Text File  |  1994-08-23  |  7KB  |  132 lines
  1. PYTHON RELEASE NOTES FOR THE MACINTOSH
  2.  
  3. VERSION 1.1
  4.  
  5. For the most part, Python on the Mac works just like Python under UNIX.
  6. The most important differences are:
  7.  
  8. - Since there is no shell environment on the Mac, the start-up file
  9.   has a fixed name: PythonStartup.  If a file by this name exists
  10.   (either in the current folder or in the system folder) it is executed
  11.   when an interactive interpreter is started.
  12.  
  13. - The default search path for modules is different: first the current
  14.   directory is searched, then the subdirectories 'lib', 'lib:stdwin' and
  15.   'demo'.  As always, you can change this (e.g. in your PythonStartup
  16.   file) by assigning or appending to sys.path -- use Macintosh pathnames!
  17.   (The default contains no absolute paths because these are unlikely
  18.   to make sense on other people's hard disks.)
  19.  
  20. - The user interface for typing interactive commands is different.
  21.   This is actually the THINK C console I/O module, which is based on
  22.   the Mac toolbox TextEdit.  A standard Edit menu provides Cut, Copy,
  23.   Paste and Clear (Undo is only there for Desk Accessories).  A minimal
  24.   File menu provides Quit, which immediately exits the application,
  25.   without the usual cleanup.  You can Copy from previous output,
  26.   but you can't scroll back beyond the 24x80 screen.  The TAB key
  27.   always brings you to the end of the current input line; indentation
  28.   must be entered with spaces (a single space is enough).
  29.   End-of-file is generated by Command-D; Command-Period interrupts.
  30.   There is an annoying limit in the length of an input line to a single
  31.   screen line (less the prompt).  Use \ to input long statements.
  32.   Change your program if it requires long lines typed on input.
  33.   Even though there is no resize box, the window can be resized by
  34.   dragging its bottom right corner, but the maximum size is 24x80.
  35.  
  36. - Tabs in module files are interpreted as 4 (four!) spaces.  This is
  37.   consistent with most Mac editors that I know.  For individual files
  38.   you can change the tab size with a comment like
  39.  
  40.     # vi:set tabsize=8:
  41.  
  42.   (exactly as shown here, including the colons!).  If you are consistent
  43.   in always using tabs for indentation on UNIX, your files will be
  44.   parsed correctly on the Mac, although they may look funny if you
  45.   have nicely lined-up comments or tables using tabs.  Never using tabs
  46.   also works.  Mixing tabs and spaces to simulate 4-character indentation
  47.   levels is likely to fail.
  48.  
  49. - You can start a script from the Finder by selecting the script and
  50.   the Python interpreter together and then double clicking.  If you
  51.   make the owner of the script PYTH (the type should always be TEXT)
  52.   Python will be launched if you double click it!
  53.   There is no way to pass command line arguments to Python scripts.
  54.  
  55. - The set of built-in modules is different:
  56.  
  57.   = Operating system functions for the 'os' module is provided by the
  58.     built-in module 'mac', not 'posix'.  This doesn't have all the
  59.     functions from posix, for obvious reasons (if you know the Mac
  60.     O/S a little bit).  The functions in os.path are provided by
  61.     macpath, they know about Mac pathnames etc.
  62.     
  63.   = None of the UNIX specific modules ('socket', 'pwd', 'grp' etc.)
  64.     exists.
  65.     
  66.   = Module 'stdwin' is always available.  It uses the Mac version of
  67.     STDWIN, which interfaces directly with the Mac toolbox.  The most
  68.     important difference is in the font names; setfont() has a second
  69.     argument specifying the point size and an optional third one
  70.     specifying the variation: a single letter character string,
  71.     'i' for italics, 'b' for bold.  Note that when STDWIN is waiting
  72.     for events, the standard File and Edit menus are inactive but
  73.     still visible, and (most annoyingly) the Apple menu is also inactive;
  74.     conversely, menus put up by STDWIN are not active when the Python is
  75.     reading from the keyboard.  If you open Python together with a text
  76.     file containing a Python script, the script will be executed and
  77.     a console window is only generated when the script uses standard
  78.     input or output.  A script that uses STDWIN exclusively for its I/O
  79.     will have a working Apple menu and no extraneous File/Edit menus.
  80.     (This is because both stdwin and stdio try to initialize the
  81.     windowing environment; whoever gets there first owns the Apple menu.)
  82.     LIMITATIONS: a few recent additions to STDWIN for X11 have not yet
  83.     been added to the Mac version.  There are no bitmap objects, and
  84.     the setwinpos() and setwinsize() methods are non--functional.
  85.  
  86. - Because launching an application on the Mac is so tedious, you will
  87.   want to edit your program with a desk accessory editor (e.g., Sigma
  88.   edit) and test the changed version without leaving Python.  This is
  89.   possible but requires some care.  Make sure the program is a module
  90.   file (filename must be a Python identifier followed by '.py').  You
  91.   can then import it when you test it for the first time.  There are
  92.   now three possibilities: it contains a syntax error; it gets a runtime
  93.   error (unhandled exception); or it runs OK but gives wrong results.
  94.   (If it gives correct results, you are done testing and don't need
  95.   to read the rest of this paragraph. :-)  Note that the following
  96.   is not Mac-specific -- it's just that on UNIX it's easier to restart
  97.   the entire script so it's rarely useful.
  98.   
  99.   Recovery from a syntax error is easy: edit the file and import it
  100.   again.
  101.   
  102.   Recovery from wrong output is almost as easy: edit the file and,
  103.   instead of importing it, call the function reload() with the module
  104.   name as argument (e.g., if your module is called foo, type
  105.   "reload(foo)").
  106.   
  107.   Recovery from an exception is trickier.  Once the syntax is correct,
  108.   a 'module' entry is placed in an internal table, and following import
  109.   statements will not re-read the file, even if the module's initialization
  110.   terminated with an error (one reason why this is done is so that
  111.   mutually recursive modules are initialized only once).  You must
  112.   therefore force re-reading the module with reload(), however, if this
  113.   happens the first time you try to import the module, the import statement
  114.   itself has not completed, and your workspace does not know the module
  115.   name (even though the internal table of moduesl does!).  The trick is
  116.   to first import the module again, then reload it.  For instance,
  117.   "import foo; reload(foo)".  Because the module object already exists
  118.   internally, the import statement does not attempt to execute the
  119.   module again -- it just places it in your workspace.
  120.   
  121.   When you edit a module you don't have to worry about the corresponding
  122.   '.pyc' file (a "compiled" version of the module, which loads much faster
  123.   than the textual version): the interpreter notices that the '.py' file
  124.   has changed (because its modification time has changed) and ignores the
  125.   '.pyc' file.  When parsing is successful, a new '.pyc' file is written;
  126.   if this fails (no write permission, disk full or whatever) it is
  127.   silently skipped but attempted again the next time the same module
  128.   is loaded.  (Thus, if you plan to place a Python library on a read-only
  129.   disk, it is advisable to "warm the cache" by making the disk writable
  130.   and importing all modules once.  The standard module 'importall' helps
  131.   in doing this.)
  132.